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SECTION  I 


INTRODUCTION  TO  THE  BASIC  MODEL 


SOFTWARE  COST  ESTIMATING  ENVIRONMENT 

Estimating  the  costs  for  developing  and  operating 
large  scale  computer  programs  (software)  is  an  endeavor 
subject  to  extensive  error.  Schwartz  (Ref  8:56)  notes 
that  underestimation  by  a factor  of  2.5  is  common,  while 
overestimations  are  unheard  of.  Devenny  (Ref  3)  presents 
data  which  indicates  underestimation  factors  ranging  from 
1.1  to  2.6  at  the  Air  Force  Systems  Command's  Electronic 
Systems  Division  (ESD),.  Clapp  (Ref  2:9),  in  her  study 
of  software  cost  estimating  methods,  notes,  "There  is 
only  one  real  problem  with  software  cost  estimation: 
overruns. ” 

The  literature  is  replete  with  reasons  why  software 
cost  estimating  has  historically  been  so  difficult.  How- 
ever, four  major  obstacles  seem  to  predominate: 

1.  Requirements  are  often  ill-defined, 

2.  Available  models/methodologies  are  overly  sim- 
plistic, 

3.  Large,  homogeneous  data  bases  for  mode 1/me thodo logy 
development  do  not  exist,  and 

4.  Past  research  efforts  have  not  committed  enough 
resources  for  successfully  accomplishing  their  often 
ambitious  objectives. 

REPORTING  SEQUENCE  AND  RATIONALE 

The  development,  implementation,  test,  and  subsequent 
modification (s)  of  this  computer  model  will  be  accomplished 
by  a series  of  ESD  Technical  Reports  (TRs)  . This  first  TR 


lays  out  the  model  concept  and  serves  to  introduce  it  to 
the  software  cost  estimating  community.  The  second  TR 
will  depict  the  model's  detailed  design,  and  will  include 
program  flowcharts,  a listing  of  the  source  code,  and 
examples  of  the  model's  use.  The  third  TR  will  report  on 
the  model's  performance  against  actual  costs  on  selected 
software  projects.  Subsequent  TRs  will  report  on  modifi- 
cations to  the  basic  model  as  reflected  in  subsequent 
version  releases. 

The  rationale  for  issuing  technical  reports  concurrent 
with  model  development  is  to  encourage  maximum  participa- 
tion on  the  part  of  the  software  cost  estimating  community. 
Only  by  doing  so  can  we  overcome  the  lack  of  a large  homo- 
geneous data  base  at  BSD  (and  elsewhere)  for  testing  and 
refining  the  model.  Thus,  this  model  will  be  tested  and 
refined  via  widespread  dissemination,  use,  and  feedback. 

REPORT  OUTLINE 


In  Section  III  of  this  report,  we  discuss  the  basic 
model  concept,  and  discuss  each  submodel,  or  stage.  In 
Section  IV , we  discuss  the  computer  implementation  of 
the  model,  with  emphasis  on  operation  options  which  will 
be  available  to  the  user.  Section  V discusses  how 
future  versions  of  the  model  will  be  modified  to  handle 
uncertainty  statistically. 


SECTION  II 
MODEL  OVERVIEW 


The  basic  model,  shown  in  Figure  I,  consists  of  five  ' 
stages:  SIZING,  MANPOWER,  SCHEDULE,  MANLOADING,  and  COST. 

At  a top  level,  SIZING  serves  to  transform  software 
functional  characteristics  into  estimates  of  computer 
program  size.  MANPOWER  combines  a sizing  estimate  with 
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characteristics  of  the  development  environment  to  estimate 
required  manpower  for  development  and  operation.  SCHEDULE 
employs  size  to  generate  a phase-oriented  development 
schedule,  and  MAHLOAOING  serves  to  spread  the  estimated 
manpower  over  this  schedule.  Finally,  COST  serves  to 
generate  constant  and  then-year  cost  estimates  based  on 
the  time-phased  manloading  profile. 

The  next  section  describes  each  stage  in  more  detail. 


SECTION  III 
STAGE  DESCRIPTIONS 


SIZING 


Virtually  every  parametric  software  cost  model  is 
based  in  whole  or  in  part  on  an  estimate  of  computer  pro- 
gram size,  measured  in  terms  of  source  or  o.bject  instruc- 
tions. Accurate  estimates  of  program  size  'are  usually  not 
available  until  detailed  technical  design  analyses  of  the 
programs  in  question  have  been  performed.  Unfortiinately, 
the  cost  analyst  is  often  required  to  provide  a cost 
estimate  prior  to  the  accomplishment  of  these  design 
analyses,  working  only  from  a system  concept.  SIZING 
serves  to  estimate  program  size  based  upon  system  func- 
tional requirements  and  proposed  hardware  characteristics.' 

SIZING  uses  one  or  both  of  two  estimating  relation- 
ships (ERs)  to  estimate  size:  a core  requirements  ER  and 
an  analogy  ER. 

C0RE_REQOTMMEOTS  ER 

Regressing  upon  data  collected  by  Johns  Hopkins 
University  and  the  MITRE  Corporation,  Doty  Associates 
obtained  the  following  ER  for  memory  size  requirements  as 
a function  of  application,  number  of  major  functions  to 
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be  performed  by  the  software,  word  size,  and  processor 
cycle  time  (Ref  4:173) : 


(Nf.332^^.l47^^-.770) 

where 

exp  » 2,718 

M « Memory  size  in  thousands  of  words  of  object  code 

Nf  » Number  of  major  fvinctions  (e.g.,  target  tracking, 
target  identification,  system  monitoring,  display, 
steering,  etc)  to  be  performed  by  the  software. 

■ Word  size  in  bits 
s 

t^  » Processor  cycle  time*  in  microseconds 

k » A constant  dependent  on  application 
2.573  for  signal  processing  ' 

2.727  for  missile  fire  control 
2.781  for  Interfacing 
3.412  for  communication 
3.565  for  navigation 
4.046  for  command  and  control 
4.451  for  weapon  fire  control 

2 

The  coefficient  of  determination  (R  ) for  this  ER  is 
.52,  and  the  standard  error  is  .086  In  units. 

ANALOGY  ER 


In  the  same  study,  Doty  derived  the  following  ER  for 
size  by  analogy  to  similar  (existing)  software  (Ref  4:174) 


-.678 


.678 


M » M (N 

a fa 


♦Time  to  either  retrieve  or  store  a word  in  processor 
memory . 


1 

! 
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where 


M - Size  of  the  proposed  program  in  thousands  of 
object  words 

= Size  of  the  analogous  programs  in  thousands  of 
object  words 

= Number  of  major  functions  performed  by  the 
analogous  software 

= Projected  number  of  major  functions  to  be 
performed  by  the  new  software. 

Doty  does  not  report  either  the  coefficient  of  deter- 
mination nor  the  standard  error  for  this  ER. 

WORDS  TO_OBJECT  TO_SOURCE  COW^SIONS 

The  core  requirements  and  analogy  ERs  estimate  size 
in  terms  of  object  words.  Since  MANPOWER  employs  ERs 
based  upon  object  and  source  instructions,  the  sizing 
estimate  expressed  in  words  must  be  converted  to  instruc- 
tions. 

To  transform  from  words  to  object  instructions,  the 
analyst  multiplies  M by  the  blend  factor  (ratio  of  average 
nximber  of  instructions  per  core  word  required  for  a 
process)  . 

To  transform  object  instructions  to  source  instruc- 
tions, the  analyst  evaluates  the  following  expression 
developed  by  Doty  (Ref  5:D-5) : 

I,  - - «> 

where 

Ig  * Program  size  in  source  instructions 
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I = Program  size  in  object  instructions 
o 

= Fractional  percentage  of  program  to  be  imple- 
mented in  Higher  Order  Language  (HOL) 

Ejj  = HOL  expansion  ratio  (average  number  of  object 
instructions  generated  per  source  instruction 
after  program  compilation) . 

If  the  code  is  to  be  written  in  Assembly  language 

(a  source  language  that  includes  symbolic  machine  language 

statements  in  which  there  is  a one-to-one  correspondence 

with  the  executable  instruction  and  data  formats  of  the 

computer) , then  = 0 and  I = I . 

h ^ so 

As  shown  in  Figure  I,  the  output  of  SIZING  (Object 

and/or  Source  Instructions) , serves  as  input  to  MANPOWER 

and  SCHEDULE.  (Specifically,  MANPOWER  uses  I and  I , 

and  SCHEDULE  uses  I .)  ® 

o 

MANPOWER 


MANPOWER  serves  to  estimate  total  manpower  requirements 
through  the  use  of  ERs  which  employ  estimated  size  and 
environmental  factors  as  the  independent  variables.  The 
ERs  are  shown  in  Table  I,  along  with  their  coefficients  of 
determination  and  standard  errors. 

For  those  situations  where  the  sizing  estimate  is  in 
source  instructions,  and  is  less  than  10,000  instructions, 
the  Table  I ERs  are  of  the  form 
14 

b n 

MM  = al„  / ‘ f. 

3 1“1  1 '• 

where 

MM  = Total  manmonths  to  develop  the  software 
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APPLICATION 

SIZING 

UNITS 

ESTIMATED 

SIZE 

DOTI 

ESTIMATING 

heutionship 

COEFFICIENT 
OF  DETER- 
MINATION 

STANDARD 

S 

C 

OBJECT 

ALL 

MM 

1.068 

- 4.4951 

.74 

72.1 

I 

E 

N 

mm 

MM 

1.019 

- 7.0541 

00 

• 

72.1 

T 

I 

SOURCE 

< lOK 

MM 

1.019 

- 2.0111  n 

.90 

2.6 

F 

I 

MM 

1.019 

- 7.0541 

00 

• 

72.1 

6 

C C 

0 0 

M N 

M & T 

A R 

N 0 

D L 

OBJECT 

ALL 

1.228 

MM  - 4.5731 

.78 

41.1 

SOURCE 

^ lOK 

1.263 

MM  - 4.0891 

.80 

41.1 

< lOK 

.89 

1.9 

1.263 

MM  - 4.0891 

.80 

41.1 

B 

U 

S 

I 

N 

E 

S 

s 

OBJECT 

ALL 

•784 

MM  « 2.8951 

.48 

12.4 

SOURCE 

^ lOK 

.781 

MM  - 4.4951 

.61 

10.7 

< lOK 

.78 

••  1.8 

.781 

MM  - 4.4951 

.61 

10.7 

u 

T 

I 

L 

I 

T 

Y 

OBJECT 

ALL 

.719 

MM  - 12.0391 

.30 

58.1 

SOURCE 

^ lOK 

.811 

‘ MM  - 10.0781 

.45 

51.7 

< lOK 

inuuuji 

.61 

2.3 

, .811 

1 MM  - 10.0781 

.45 

51.7 

MANPOWER  ERs 

I 

TABLE  I 
8 


I “ Number  of  source  instructions 

9 

a,b  = Constants  (derived  via  regression  analysis) 
rif^  ■ Product  of  environmental  factors 

In  all  other  cases,  fl  f =1. 

i=l  i 

i 

Table  II  shows  the  values  assigned  to  the  environmental 
factors  if  the  appropriate  environmental  conditions  are  or 
are  not  present. 

SCHEDULE 

SCHEDULE  serves  to  estimate  the  development  schedule, 
and  position  it  into  phases 

DEVELOPMmJT  SCHEDULE 

i 

j Regressing  upon  data  from  74  development  programs, 

Doty  derived  an  ER  for  development  time  given  by 

' .667 

t - I /(99.25  + 2.331  ) 

Do  o 

where 

*»  "Reasonable"  development  time,  in  months 

I^  « Number  of  delivered  object  instructions 

Additionally,  Doty's  analyses  yielded  average  dis- 
tribution of  schedule  and  expenditures  as  shown  below 

Number  of  Months 

Pha se  Per  Ph£se  Cumulative 

Analysis  .It'  .It 

i Design  .33  t°  .43  t° 

' D D 


I 

i 
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ENVIRONMENTAL  FACTOR  VALUES 


Phase 


Number  of  Months 


Code 
Checkout 
Package  Test 
System  Test 

MANLOADING 

The  MANLQADING  stage  serves  to  spread  the  manpower 
provided  by  MANPOWER  over  the  schedule (s)  provided  by 
SCHEDULE.  To  do  SO,  it  applies  the  software  life  cycle 
curve  developed  by  Putnam  (Ref  7) . 

Putnam's  software  life  cycle  curve  is  a tailored 
version  of  a generalized  project  life  cycle  manloading 
curve  derived  and  observed  by  Norden  of  IBM  (Ref  6) . The 
curve,  illustrated  in  Figure  II,  is  given  by 


Per  Phase 


.09  tj3 
.085  tZ 
.20  t 
.195  t 


Cumulative 


.52  t 
.605  t: 
.805  tZ 
1.0  t 
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Y = 2 Kate 


\<rhere 

Y ■ manmonths/month 
K = total  life  cycle  manpower 
a = shape  parameter 
e = 2.71828 


Applying  the  Nordeh  curve  to  U.S.  Army  Computer  Systems 
Command  software  developments,  Putnam  shows  that  Norden's 
curve  can  be  written  as 


Y 


(Tc/t  ) te 


2 , 

-t  /2t 


where 

tjj  is  approximately  equal  to  the  development  duration. 

In  hii  papeg:S^  (Ref  7),  Putnam  uses  first  principles 
from  physics  to  prove  that  the  parameters  K (total  required 
manpower)  , tjj  (development  time)  and  K/t  ^ (which  he 
defines  as  "system  difficulty") , are  funaamental  parameters 
of  any  software  project.  Furthermore,  he  states 

"These  parameters  are  natural  attributes  of  a 
system.  Systems  are  inherently  stable  and  will 
seek  (or  be  driven  to)  their  natural  parameters." 
(Ref  7x2) 

He  also  corroborates  his  theoretical  findings  with  empiri- 
cal evidence  on  past  Army  Computer  Systems  Command  soft- 
ware projects. 
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The  hypothesis  that  development  schedule  is  a "natural" 
parcuneter  which  systems  will  be  driven  to  also  corroborates 
well  with  experience  outside  of  Army  Computer  Systems 
Command.  For  example,  at  ESD  the  validity  of  the  hypoth- 
esis is  evident  in  view  of  the  fact  that  virtually  all 
software  developments  have  historically  experienced 
schedule  slips.  (One  might  argue  that  these  slips  are  the 
result  of  optimism  in  planning  a schedule,  acting  in  place 
of  realism  with  respect  to  a natural  schedule.) 

In  further  support  of  this  natural  schedule  phenomenon. 
Brooks,  manager  of  the  IBM  360  Operating  System  develop- 
ment, observes  that  "the  urgency  of  the  patron  may  govern 
the  scheduled  completion  of  the  task,  but  it  cannot  govern 
the  actual  completion."  (Ref  1:47),  He  then  goes  on  to 
state  "Brook's  Law",  which  is  consistent  with  Putnam's 
findings: 

"Adding  manpower  to  a late  software  project  makes 
it  later."  (Ref  1:48) 

To  demonstrate  this  consistency,  we  note  that  Putnam's 
difficulty  factor  D ■ is  also  hypothesized  and 

demonstrated  empirically  to  be  a natural  system  parameter. 
Such  being  the  case,  an  increase  in  manpower  (K)  must  be 
accompanied  by  a^  increase  in  development  time  (t  ) if 
difficulty  is  to  remain  constant. 

Table  m depicts  Doty's  observation  of  expenditure 
profiles  in  the  general  case.  In  Table  IV,  we  compare 
Doty's  expenditure  profile  with  the  manpower  expenditure 
profile  obtained  by  evaluating  the  integral  form  of 
Putnam's  curve  at  the  appropriate  points  in  the  develop- 
ment schedule,  and  note  a close  correlation. 

MAHLOADING  uses  Putnam's  curve  to  time  phase  the 
development  manpower  generated  by  MANPOWER  against  a 
development  schedule  generated  by  SCHEDULE.  Additionally, 
if  the  user  so  desires,  he  can  enter  an  externally  provided 
schedule  (such  as  one  imposed  by  higher  headquarters) . In 
this  case,  MANLOADING  generates  two  manloading  profiles 
(against  natural  and  imposed  schedules) . 
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DEVELOPMENT 

PHASE 

DEVELOPMEWT 

MILESTONE 

AVERACS  DISTRIBUT] 

CON  OF  EFFORT 

' SCHEDULE 

' EXPENDITURES 

15 

CUM?& 

95— 

CUM^ 

ANALYSIS 

CCMffLETE  SYS. 
DESIGN  (PDR) 

10 

10 

3 

3 

DESIGN 

COMPLETE  PKG. 
DESIGN 

25 

35 

17 

20 

COMPLETE  UNIT 
DESIGN 

8 

43 

7.5 

27.5 

CODING 

COMPLETE  UNIT 
CODING 

9 

52 

11 

38.5 

CHECKOUT 

COMPLETE  UNIT 
DEBUGGING 

8.5 

60.5 

10 

48.5 

TEST  AND 
INTEGRATE 

COMPIETE  fKG. 
TEST 

20 

80.5 

27 

75.5 

COMPLETE  SYS. 

test 

19.5 

100 

24.5 

100 

DISTRIBUnON  OF  DEVELOPMENT  EFFORT 
TABLE  III 


DEVELOPMENT 

MHESTONE 

CUMULATIVE 

DEVELOPMENT 

CUMULATIVE 

EXPENDITURES 

(DOTY) 

CUMULATIVE 

MANPOWER 

EXPMDITOBES 

(PUTNAM) 

COMPLETE  SYS. 
DESIGN 

.1 

% 

1.395 

COMPLETE  PKG. 
DESIGN 

.35 

20^ 

15.195 

COMPIETE  UNIT 
DESIC3I 

.43 

27.595 

22.695 

COMPLETE  UNIT 
CODING 

.52 

38.535 

32.395 

COMPLETE  UNIT 
DEBUGGING 

.605 

48.595 

42.395 

COMPLETE  PKG. 
TEST 

.805  t , 
a 

75.595 

71.095 

COMPLETE  SYS. 
TEST 

1.0 



100.095 

CORRELATION  R 

100.095 

^.998 

DOTT  VS  PUTNAM  EXPENDITUHE/tlANPOWER  PROFILE 


TABIE  IV 
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UFE^TCLEJlAtnp^piG 

In  generating  the  manloading  profile,  MANLOADING  employs  two 
observations  made  by  Putnam*  The  first  is  that  development 
mai^ower  (area  under  the  curve  up  to  t > t^)  Is  approximately  39^ 
of  total  life  cycle  manpower.  The  second  Is  that,  In  reality,  the 
manpower  level  for  maintenance  levels  off  at  t > 2*38  t.,  to  Its 
value  of  Y at  that  point.  As  shown  In  Figure  III,  tbere  t . and  Y 

G flUAX 

are  noxmallzed  to  1,  MANLOADING  assumes  a level  manloading  at  t-  2,36  t^ 
and  sliiply  Increments  time  until  the  area  under  the  curve  equals  K, 
at  which  time  the  system  life  cycle  Is  assumed  to  be  over. 

As  shown  In  Figure  I,  the  dual  schedule  output  of  MANLOADING 
serves  as  liput  to  COST. 


COMPLETE 

BEGIN  STEADY-STATE 

END 

SYSTEM  _ 

MAINTENANCE  ^ 

PROGRAM 

NOBMALIZED  MANLOADING  CURVE 
Figure  HI 
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COST 

To  this  point,  the  model  has  generated  time  phased 
life  cycle  manloading  requirements.  COST  serves  to 
generate  constant  and  then-year  (escalated)  cost  estimates 
by  cost  category  and  budget  appropriation. 

DEV^OPMraiT  COST 

To  determine  development  costs,  COST  multiplies  the 
time  phased  manloading  profile  by  a user-supplied  average 
labor  rate,  in  dollars  per  manmonth  (including  overhead, 
and  general  and  administrative  costs,  as  appropriate) . 

It  then  multiplies  the  estimated  time-phased  labor-related 
costs  by  cost  factors ''derived  by  Doty  for  secondary 
resources  such  as  computer  time,  documentation  reproduc- 
tion, and  travel.  COST  then  allocates  estimated  costs  on 
a time  phased  basis  to  the  following  cost  categories: 

Systems  Engineering  (Labor  costs  for  analysis  phase) 

Computer  Programs  (Labor  costs  from  start  of  design 
phase  to  end  of  package  test) 

Systems  Test  (Labor  costs  for  systems  test  phase) 

Development  Facilities  (Computer  time) 

Data  (Docvimentation  reproduction) 

Project  Management  (Travel) 

Overhead 

General  and  Administrative 

Fee 

In  the  original  model  version,  these  factors  will  be 
single  valued  percentages.  The  user  can  choose  to  enter 
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his  own  percentages,  or  use  default  values  pre-loaded  in 
the  model. 


As  an  option,  the  user  can  specify  the  base  year  for 
his  average  labor  rate,  and  expected  starting  month  for  the 
development.  COST  then  presents  the  time-phased  cost 
estimate  for  the  above  nine  cost  categories  by  applying 
approved  Office  of  the  Secretary  of  Defense  (OSD)  escala- 
tion factors  for  the  3600  (research  and  development) 
appropriation. 

TR^SITIONjCOSTS 

For  purposes  of  this  model,  the  transition  period  is 
defined  to  be  that  portion  of  the  life  cycle  between  end 
of  development  and  sta'rt  of  steady  state  maintenance. 
Activities  during  this  period  involve  operational  test 
and  evaluation,  enhancement,  and  correction  of  major 
design  and  coding  errors.  As  shown  in  Figure  IV,  manpower 
during  this  period  of  time  is  assumed  to  consist  of  a mix 
of  contractor  and  government  personnel,  with  the  government 
level  building  up  linearly  from  zero  to  the  steady  state 
maintenance  level  during  this  period. 

During  this  phase,  COST  first  calculates  the  govern- 
ment level  and  siibtracts  it  from  the  total  level.  It 
then  costs  the  contractor  segment  (for  all  nine  cost 
categories)  in  the  same  fashion  as  the  development  phase.  . 
It  costs  the  government  portion  by  applying  user-supplied 
coat  factors  found  in  AFM  173-10,  USAF  Cost  Planning 
Factors. 

5«nJTEa»NCE  COSTS 

COST  estimates  steady-state  maintenance  costs  by  " 

applying  user-supplied  coat  factors  found  in  AFM  173-10 
; to  the  steady-state  maintenance  level. 

\ C0ST_RISK 

COST  calculates  time-phase  development,  transition, 

I and  maintenance  costs  for  manloading  profiles  based  upon 
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» 

' both  estimated  development  schedule  and  external,  imposed 

development  schedule  (if  one  is  provided) . In  the  case 
where  an  external  schedule  is  provided,  the  model  takes 
the  cost  differences  between  the  two  profiles  on  a month- 
by-month  basis  and  generates  a time-phased  schedule  cost 
risk  profile. 
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SECTION  IV 


MODEL  FEATTOES 


In  Section  m,  we  discussed  the  basic  model  structure. 

In  this  section,  we  discuss  some  of  the  features  which 
will  be  implemented  in  the  computer  version. 

raTRY  POINT  SEI^ICTipN 

Depending  upon  where  the  software  project  is  in  its 
life  cycle,  the  analyst  may  wish  to  by-pass  certain  stages. 
For  example,  if  the  project  has  progressed  beyond  detailed 
design,  the  cost  analyst  may  have  contractor  provided 
sizing  estimates  in  which  he  has  high  confidence?  in  that 
case,  he  would  prefer  to  by-pass  SIZING. 

The  model  will  be  implemented  so  as  to  allow  the 
analyst  to  select  his  entry  point. 

BAgCjCHECKjOPTION 

This  option  will  allow  the  analyst  to  exercise  certain 
stages  in  reverse,  as  a check  on  data  he  may  have  received 
from  other  sources.  For  example,  suppose  he  has  externally- 
provided  estimates  of  size,  manpower,  and  development 
schedule  and  chooses  to  enter  the  model  at  MANLC3ADING.  By. 
exercising  the  bench-check  option,  the  analyst  can  solve* 
the  inverse  of  the  Doty  ERs  to  obtain  an  estimate  of  size  , 
as  a function  of  manpower  and  environmental  factors.  The 
resulting  estimated  size  then  serves  as  a check  on  the 
externally-provided  sizing  estimate. 

multiple^runs  M0DE_ 

For  purposes  of  sensitivity  analysis,  the  analyst  may 
wish  to  perform  multiple  runs,  varying  only  a single 
variable  from  nin  to  run.  In  the  Multiple  Runs  Mode,  the 
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program  will  ask  the  analyst  to  declare  that  variable 
which  will  vary  from  run  to  run,  and  will  ask  for  the 
value  of  only  that  variable  on  subsequent  runs. 

INTERIM  STAGE  OUTPOT_MODE 

In  normal  operation,  the  model  will  provide  only  time 
phased  cost  profiles  as  output.  In  the  Interim  Stage 
Output  Mode,  the  analyst  will  be  able  to  declare  stages 
for  which  he  desires  to  receive  output.  For  example,  by 
declaring  Stage  4 (MANLOADING),  the  analyst  will  direct 
the  model  to  output  the  time-phased  manloading  profiles 
generated  by  that  stage. 
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SECTION  V 


UNCERTMNTY 


In  the  initial  version  of  the  model,  uncertainty  will 
be  handled  solely  by  user-conducted  analysis  of  variations 
in  output  as  a function  of  variations  in  input.  Although 
such  sensitivity  analyses  provide  a first  cut  at  analyzing 
the  effects  of  uncertainty  in  specifying  the  system,  they 
do  not  capture  uncertainty  inherent  to  parameters  and 
relationships  internal  to  the  model. 

Subsequent  versions  of  the  model  will  handle  uncer- 
tainty inherent  to  thf  model  by  employing  a combination  of 
statistical  analyses  on  the  regressions  underlying  the 
ERs,  and  Monte  Carlo  sampling  techniques  on  those  para- 
meters and  relationships  derived  by  techniques  other  than 
regression. 

Detailed  discussion  of  the  handling  of -uncertainty  via 
statistical  and  Monte  Carlo  techniques  will  be  contained 
in  a siibsequent  Technical  Report. 
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SECTION  VI 


SUMMARY 


This  report  has  outlined  conceptually  a software  cost 
model  incorporating  and  integrating  recent  and  relevant 
research  in  various  aspects  of  the  software  life  cycle. 
The  computer  version  of  this  model  is  currently  (Winter 
1978)  being  designed  and  implemented  at  ESD  for  use  as  a 
research  and  possible  estimating  tool. 

The  motivation  for  publicizing  the  model  prior  to  its 
actual  implementation  is  to  motivate  interest  and  dis- 
cussion within  the  software  cost  estimating  conimunity. 
Hopefully,  this  interest  and  discussion  will,  in  turn, 
result  in  widespread  model  usage  and  experimentation, 
with  resulting  successes  and  failures  relayed  back  to  ESD 
Such  feedback  will  be  the  primary  means  for  testing  and 
improving  the  model. 

•• 

Individuals  interested  in  discussing  the  model  are 
encouraged  to  call  Capt  Joseph  Duquette  at  (617) -861- 
2795,  or  AUTOVON  478-2795.  ' 
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